Build your own Router

Automatic recovery

By now we've got a working iptables script where ports can be opened and forwarded into our LAN. But just in case the server is reset, we need to ensure the script is loaded every time the networking comes up on the machine.

While there are a lot of ways to achieve this, I prefer using the 'post-up' method. To be able to use this method, we first need to make the script executable. This is done by chmoding it to '700', so issue "chmod 700 <path_to_script>".

Next step is to open up your favourite editor and edit /etc/network/interfaces. Look for the part that defines your external interface and add a line to the bottom of it containing the following line:

post-up <path_to_script>

Each time the interface is brought up, the script is executed...which means that you can now safely rest, knowing your network is protected at any time.

DHCP & DNS on the internal network

Now that our firewalling and routing needs are satisfied, it's time to think about the users on our LAN. Nothing is easier then plugging in the wire and having IP and DNS information being set automatically. We already mentioned that we'd be setting up a DHCP server in this part, so let's get to it!

There are plenty of packages out there that offer DHCP services for your network, but I prefer dnsmasq. Dnsmasq is an intelligent package that combines DHCP and DNS services (among others), and is easy to set up.

As always, it all begins by installing the package. Issue "apt-get install dnsmasq" and watch how apt does its magic. The configuration is located in /etc/dnsmasq.conf, which we'll open with our preferred editor. The file should be self explanatory, but I'll guide you through. To activate the DHCP server of dnsmasq, simply uncomment the line which contains "dhcp-range=192.168.0.50,192.168.0.150,12h". The server will now dish out IPs ranging from 192.168.0.50 to 192.168.0.150 with a lease time of 12 hours.

Another function of dnsmasq is to act as a DNS server. With this service, you can make sure that a specific machine on your network always gets the same IP address, and that IP is also added to the network's DNS server. To make this work, you first have to add your machines to the /etc/hosts file of the router. The syntax for that file is "<ip_address> <hostname>". So we'll edit /etc/hosts with our chosen text editor, and add "192.168.0.100 triton" under the IPv4 and IPv6 Localhost Aliases section.

Now, switch back to the dnsmasq configuration file and look for the line which contains "dhcp-host=judge". Add subsequent lines like it to the file - so if you have 'triton' and you have added it to /etc/hosts, add the line "dhcp-host=triton". Don't forget to restart dnsmasq after you are done by issuing "/etc/init.d/dnsmasq restart"!

Now the IP addresses of your DHCP clients get resolved internally, so you can safely forget all about them and just type "ssh triton" or anything else you need to do.

Closing words

This small article should give you some insights into what makes a router tick. Whether it's a fifteen quid shelf-warmer or a full-on high-end corporate firewall, the basic structure is the same inside. The greatest benefit to building one yourself is the amount of flexibility and control, as well as the learning process of how your network...well, works. For that, I've just shown the very tip of a very big iceberg.

Unfortunately, the biggest downside is iptables and its documentation (or lack thereof). A lot of open source packages have great documentation, and theoretically so does iptables - you can find every bit you could ever need in its main pages alone. However, most of its practical documentation seem to require a fairly solid knowledge of ipchains, the predecessor of iptables. This self-referential junk only adds to the complexity of building a firewall or router, and detracts from people learning it at all.

Are there other ways to get where you're going? Sure, and we'll look at a couple of them in an upcoming article. Some of the Linux pre-packaged firewall programs are really quite impressive and robust. However, for what iptables lacks in grace, it imparts in wisdom of how your network actually functions.

I may not be able to explain everything in one article, but there's a good reason for that. Iptables is a very flexible and also incredibly complex package to understand in depth. However, nothing is impossible if you put your mind to it, including this. And if it gets you more curious, you can read up on some of the other guides out there that offer further insights to the interested reader. Just keep in mind, hardly any guide on iptables offers copy/paste solutions.